1. Field of the Invention
The exemplary, illustrative, technology herein relates to systems, software, and methods for implementing and managing security policies for mobile and other devices of diverse types. The technology herein has applications in the areas of mobile device and enterprise network security.
2. Description of the Related Art
Security and configuration managers manage mobile devices that are part of their network in order to maintain network security, manage use of resources, and detect or prevent misuse of such devices, but often do not have the expertise or means to understand, manage, and configure the policies on the different device types in use, using device-appropriate policy management protocols and policy servers. The plethora of such policy management protocols, policy servers, device types, and policy requirements increases the difficulty of maintaining an appropriate level of configuration control over mobile devices that may connect to a given network. Network operators can end up with a collection of separate policies, defined and managed using various policy management protocols, being served from a disparate group of policy sources, using a variety of policy servers to devices with varying capabilities for policy implementation and reporting. This can result in inadequate policy implementation and enforcement, increased costs, and inefficient use of resources as well as unacceptable risks to network security.
Policies comprise one or more policy elements that define one or more aspects of the mobile device's configuration. A policy is typically applied as a unit to a mobile device's configuration. Different device models, from the same or different manufacturers, may have differing policies that can be applied to them. Thus, the policy elements used, and their settings may vary from device to device. Policies are defined in various ways, depending on the device type they apply to, the policy server used to install them and/or verify device compliance with them. Policies are disseminated from policy servers, which act as a source of policies for transport to the devices they apply to, using various policy management protocols. Policy management protocols comprise protocols for interaction between policy servers and devices receiving policies. These protocols can provide means not only to transfer the policy to the receiving device or devices, but also to manage policies on those devices, such as by verifying that the policy has been received by the device, verifying device compliance with the policy, removing the policy, updating the policy, or other policy-related activities. The manner in which these functions are accomplished varies from one policy management protocol to another, and the functions supported also vary.
Mobile devices can have a plurality of policies applied at any given time, or sequentially over a period of time. Policies can also be stored on some mobile devices, and activated or deactivated as required. On other mobile devices, policies cannot be stored, but are activated when set, and remain activated until a newer policy is set. Most devices incorporate a method for resetting the device to “factory default” settings, which typically deactivates all policies. Multiple policies can also be active on the same mobile device simultaneously, so long as the policies do not conflict. For example, if a first policy requires e-mail to be obtained from server A, and a second policy prohibits installation of new software, there is no conflict and both policies can be active on the same device at the same time. On the other hand, if a first policy requires e-mail to be obtained from server A, and a second policy requires e-mail to be obtained from server B, there is a conflict that must be resolved.
Applying a policy to mobile devices is challenging for a variety of reasons, due to a plethora of mobile device types from various manufacturers, a plurality of management protocols developed by different mobile device vendors for setting device parameters and subsequently managing these devices, and an inconsistency between device manufacturers in the device configuration elements that are exposed on different types of mobile devices and the device configuration elements that can be managed by the possible policy management protocols supported by those devices.
Policies are provided to mobile devices using policy servers. Typically, these servers permit definition and management of policies for specific types of devices, or for a limited subset of devices that share a common policy definition. This means that a plurality of policy servers may be used to support many different types of devices. Thus, an installation might have a first policy server to manage BlackBerry™ devices, a second policy server to manage Microsoft™ Windows Mobile™ devices, and a third policy server to manage Apple iPhones™. Different policy servers may offer differing policy options and the reconciliation of these policy options and settings against an integrated security policy is tedious, time consuming, and often prone to errors. Similarly, reporting the status of device compliance using a plurality of disparate policy servers has many of the same drawbacks. Finally, different policy servers may communicate with mobile devices using their own policy management protocols, which further complicates the configuration of policies and firewalls.
Different policy management protocols may have different capabilities for setting and reporting the state of device policy elements defined within a device. This makes establishing, or determining device compliance with, security policies more difficult and error prone when a plurality of policy servers are required by use of diverse device types. For example, the Apple iPhone™ Configuration Utility requires user assistance to set configuration parameters and the user retains the ability to remove restrictions imposed by the configuration settings, while Microsoft Exchange ActiveSync™ can alter device settings without user assistance, and the BlackBerry™ Enterprise Server can set restrictions on the device user's ability to alter settings. Often, these policy management protocols manage different portions of the mobile device's configuration and are not integrated in their settings or reporting. The policy management protocol implementations can be generalized as a “policy transport”. Policy transports sometimes embedded within a broader data stream, such were policy and data are passed between an applications server and a mobile device. Well known policy transports include, for example, Microsoft ActiveSync™, BlackBerry™ Policy Service (BPS), Open Mobile Alliance™ (OMA) Device Management (OMA-DM), and Apple iPhone™ Configuration Utility. The use of a plurality of policy transports can complicate the management of firewalls and other network security systems, and reduce their effectiveness in some scenarios due to the use of different lower level network protocols or ports by diverse policy transports. In some implementations, specialized software is required to be added to a mobile device in order to make the device interoperate with a specific policy transport. This is inefficient and adds to deployment cost and complexity.
Some policy servers display and manage per-device policy compliance status information. The nature of policy compliance reported varies from policy management protocol to policy management protocol, ranging from “X policy was installed” to “Device Y has a specific setting Z”. To obtain a “whole enterprise” view of policies and device compliance, a user must manually reconcile the policy differences, the reporting differences, and ensure that the component systems in the enterprise are properly configured.
With a plethora of disparate policies and policy transports, what is needed are techniques and systems to integrate the policies and policy transports to provide an integrated enterprise-wide policy definition, management and compliance reporting system. Integrating these components requires more than simply collecting the information from two or more disparate policy servers and supplying it over an appropriate policy transport to the device(s) that must be made compliant. The information collected must be synchronized with respect to time, device and management protocol capabilities must be taken into account, conflicting policy requirements must be resolved, device compliance must be determined and optionally corrected, and techniques must be used to ensure that compliance status is collected and reported in a common format. In addition, this must be done in a manner that is efficient with respect to bandwidth use, device resource use, and delays perceptible to device users.
Microsoft Exchange ActiveSync™
Microsoft Exchange ActiveSync™ (EAS) is a protocol that connects mobile devices to Microsoft™ Exchange servers, allowing synchronization of e-mail and PIM (Personal Information Manager) data, such as tasks, calendars, and contacts, between Microsoft™ Exchange and the mobile device as well as limited policy management of the device by Microsoft™ Exchange.
Microsoft™ has implemented the EAS protocol on Microsoft™ Windows Mobile™ devices, and has licensed the protocol to a plurality of third-parties for use with a plurality of other mobile operating systems. Licensees include owners of mobile operating systems such as, for example, Nokia Symbian S60™, Sony Ericsson UIQ™, and Apple iPhone™, handset OEMs such as Motorola™, HTC™, and Samsung™, and third party synchronization vendors such as DataViz™. These vendors license and implement the client-side EAS Application Programming Interface (API).
The EAS protocol may include three relevant areas of processing: Handshake, Email/PIM Synchronization, and Policy Push. These are described below.
Handshake: Although EAS allows for push email from a server, EAS depends upon the mobile device to initiate the connection to the server. It is the device's responsibility to connect (and re-connect, if a connection is lost) to the server, to create the session over which email, PIM, and policy information can be pushed. The establishment of the session involves an authentication handshake, which identifies the device user (by Active Directory™ (AD) Username) and the device (by EAS Device ID and EAS Policy Key) to the Microsoft™ Exchange Server, associating the session with a mailbox for the purpose of email and PIM synchronization, and with a user and an AD group for the purpose of policy push. The EAS Policy Key is used as a first stage check to prevent continued communication if the Policy Key is not provided or is not valid. The User is authenticated either by passing the user's AD password in the protocol, or by using a client or machine certificate for client-side authentication of the SSL tunnel.
Email/PIM Synchronization: Both the device and the Microsoft™ Exchange server can “push” new (or changed) information to each other. For example, new email can be pushed from Microsoft™ Exchange to the device. New or modified contacts, calendar entries, and other PIM information can be pushed as well. Email sent from the device is pushed to the Microsoft™ Exchange Server, as well as PIM information created or changed on the device. The protocol specifies mechanisms for keeping changes synchronized between Microsoft™ Exchange and (multiple) devices.
Policy: The Microsoft™ Exchange Server can push policies to the device. These policies can be actions such as “Device Wipe” which causes the device to clear its memory and return the device configuration to its original factory state. Other policies can specify secure operation, including the requirement that the device lock itself after a period of (user) inactivity and require from the user a password or PIN of certain complexity to unlock. The device acknowledges receipt of such policies, so Microsoft™ Exchange can assume that the policy has been enforced.
BlackBerry™ Enterprise Server
BlackBerry™ Enterprise Server (BES) is a push-based server from Research In Motion™ (RIM™) that enables a secure, centrally managed link between BlackBerry™ devices and an organization's enterprise systems, applications, and wireless networks. It integrates with popular content sources such as e-mail and personal information management (PIM) systems such as IBM Lotus Domino™ and Microsoft™ Exchange, and is designed to provide secure access to e-mail, organizer data, instant messaging, Web browser, and other enterprise applications. It provides this access by retrieving information from enterprise content sources and “pushing” this content to a BlackBerry™ mobile device In addition to applying policies to individual devices, administrators can create groups of mobile users, then apply policies for one or more groups. Approximately 450 different policies can be applied to individual devices or groups of BlackBerry™ devices, ranging from enforcing password protection and controlling access to third party mobile applications, to controlling the use of certain device features, such as using a camera or video recording.
Some policy settings take precedence over others. For example, IT policy settings override application control policy settings. If you change an Allow Internal Connections IT policy rule to “No”, and if there is an application control policy set that allows a specific application to make internal connections, the application cannot make internal connections. Device users can make application permissions more, but never less, restrictive than what the BES server specifies. Devices ignore policy elements that are associated with features that the device does not support. For example, a policy element that disables use of a camera will be ignored by a device that does not include a camera. Errors are not generated in such situations.
Open Mobile Alliance™ Device Management
The Open Mobile Alliance™ (OMA) Device Management (DM) specification is designed for management of small mobile devices such as mobile phones, PDAs, and palm top computers. Device management includes, for example, provisioning, configuration, software installation or upgrade, and status reporting. A device may implement all or a subset of these features. Since the OMA-DM specification is intended for use with mobile devices, it is designed with sensitivity to memory and storage space limitations, communication bandwidth constraints, and security.
OMA-DM uses Extensible Markup Language (XML) for data exchange; specifically the sub-set defined by Synchronization Markup Language (SyncML). Device management is through a client-server relationship between a server and the client device being managed. OMA-DM is designed to support and utilize a variety of connection methods, such as Universal Serial Bus (USB) or RS-232 wired connections and wireless connections, such as Global System for Mobile communications (GSM), Code Division Multiple Access (CDMA), Infrared Data Association (IrDA) or Bluetooth. Transport can involve Website Project (WSP) or (Wireless Application Protocol (WAP)), Hypertext Transfer Protocol (HTTP), OBject EXchange (OBEX) or similar transport layers. Policy settings can be transferred in OMA Device Management Files (DDF), which are XML data files of known format.
The communication protocol used by OMA-DM is a request-response protocol. Authentication and challenge of authentication are included to ensure the server and client are communicating only after proper validation. The initial message from the server to a client is in the form of a notification, or alert message. Once the communication is established between the server and client, a sequence of messages is exchanged to complete a given device management task. OMA-DM provides for alerts, which are messages that can occur out of sequence, and can be initiated by either server or client. Such alerts are used to handle errors, abnormal terminations, etc.
The protocol specifies exchange of “packages” during a session. The packages consist of several messages, and the message in turn consists of one or more commands. The server initiates the commands and the client executes the commands and returns the results in a reply message. In some instances, the command includes policy elements to be set on the device. In others, the command reports aspects of the device's configuration status back to the server.
iPhone™ Configuration Profiles
iPhone™ Configuration profiles define one or more iPhone™ settings. Configuration profiles are XML files that contain device security policies and restrictions, virtual private network (VPN) configuration information, Wi-Fi™ settings, email and calendar accounts, and authentication credentials that permit devices to work with enterprise systems. Configuration profiles can be installed on devices connected via USB using the iPhone™ Configuration Utility, or configuration profiles can be distributed by email or through a webpage. When users open the email attachment or download the profile using the Safari™ web browser on their device, they are prompted to begin the Configuration profile installation process.
Configuration profiles are created by use of the iPhone™ Configuration Utility. The iPhone™ Configuration Utility enables creation, encryption and installation of configuration profiles (for devices connected via USB), among other capabilities. A configuration profile is the whole file used to configure certain settings for a device. Apple™ also refers to a “payload” as an individual collection of a certain type of settings, such as VPN settings, within a configuration profile. Configuration profiles can be locked such that a password is required to remove one from a device after it has been installed.
Configuration profile updates are not pushed to devices. Updated profiles must be manually installed by device users. As long as the profile identifier matches, and if signed, it has been signed by the same copy of the iPhone™ Configuration Utility, the new profile replaces the profile on the device. Removing a configuration profile removes policies and all of the Exchange account's data stored on the device, as well as VPN settings, certificates, and other information, including mail messages, associated with the profile.